Problem

Thanks to @diegoleme for reporting this in #6425 and proposing the bundleDependencies approach.

In a monorepo, a sync often needs to reuse an internal workspace package (like @repo/shared for helpers or types). Right now nango compile won't allow it. From the issue:

the helper has to be manually copy-pasted into the integrations folder and kept in sync by hand, which silently drifts from the source of truth

Two things cause it:

1. esbuild marks every non-relative import as external, so @repo/shared never gets bundled and is missing in the sandbox.
2. The import check throws disallowed_import for anything outside the hardcoded allowlist.

Solution

Add an opt-in bundleDependencies array to the project's package.json:

{ "bundleDependencies": ["@repo/shared"] }

Packages in that list skip the disallowed_import check and get inlined into the compiled .cjs instead of externalized. Subpaths like @repo/shared/utils match too. Safe for the sandbox
since the code is inlined at build time, and nothing changes when the field is absent.

Node built-ins are rejected. Under platform: 'node' esbuild leaves built-ins external, so listing something like "fs" would let a script reach the sandbox and skip the allowlist. They're
blocked both when the config is read and if one reaches esbuild resolution.

Closes #6425

Testing

Run: npx vitest --config ./vite.cli.config.ts run

6 tests, all run locally and passing:

• Rejects a workspace import when it's not opted in (fails with disallowed_import)
• Inlines a workspace import when opted in
• Matches subpaths like @repo/shared/utils
• Compiled .cjs on disk has the inlined code, no leftover require("@repo/shared")
• Node built-ins stay blocked even if listed
• Compile fails early with a clear error when a built-in is listed

Note: config shape/naming mirrors the issue's proposal. Happy to adjust, and I left docs out until it's confirmed.